The increasing reliance upon computer systems to collect, process, and analyze data has led to the continuous improvement of the system assembly process and associated hardware. With the improvements in speed and density of integrated circuits, the cost and complexities of designing and testing these integrated circuits has dramatically increased. Currently, large complex industrial integrated circuit testers (commonly referred to in the industry as “Automated Test Equipment” or “ATE”) perform complex testing of integrated circuit devices, such as integrated circuits, printed circuit boards (PCBs), multi-chip modules (MCMs), System-on-Chip (SOC) devices, printed circuit assemblies (PCAs), etc. The tests that must be performed may include, among others, in-circuit test (ICT), functional test, and structural test, and are designed to verify proper structural, operational, and functional performance of the device under test (DUT).
An example of an automated test is the performance of an in-circuit test. In-circuit testing, which verifies the proper electrical connections of the components on the printed circuit board (PCB), is typically performed using a bed-of-nails fixture or robotic flying-prober (a set of probes that may be programmably moved). The bed-of-nails fixture/robotic flying-prober probes nodes of the device under test, applies a set of stimuli, and receives measurement responses. An analyzer processes the measurement responses to determine whether the test passed or failed.
A typical in-circuit test will cover many thousands of devices, including resistors, capacitors, diodes, transistors, inductors, etc. Tests are typically passed to the tester via some type of user interface. Typically, the user interface allows a technician to enter various configurations and parameters for each type of device to automatically generate tests for devices of that type. However, for various reasons, frequently a fairly significant percentage (e.g., 20%) of the automatically generated tests are faulty in that when executed on a known good device under test, the test is unable to determine the status of the device or component under test. Clearly, for devices under test that include thousands of components, this results in a large number of tests that must be manually repaired. Expert technicians typically know how to repair a broken test. However, with such a large number of “broken” tests to repair, a large (and therefore, very costly) amount of time can be spent in test debug and optimization, rather than spent in actual testing of the device itself. Accordingly, a need exists for a technique for extracting and automating the expert knowledge of test technicians to repair and optimize integrated circuit tests.